Mark Slooff Regional Sales Director, OutSystems voor Agile Webapplications. Expert van Channelweb voor de topics Business Analytics, Cloud Computing en Infrastructuur.

Het denken over softwareontwikkeling en z’n uitdagingen is sinds de opkomst hiervan nogal geëvolueerd. Het begon ruim veertig jaar geleden met de traditionele watervalmethode, gevolgd door een diversiteit aan rapid application development (rad)-methoden. Ingegeven door de behoefte aan meer mogelijkheden om gedurende het project bij te sturen, winnen sinds enkele jaren de huidige Agile-ontwikkelmethoden sterk aan populariteit.

Het modelleren en genereren van applicaties geschiedde in de beginjaren van de software engineering middels de traditionele watervalmethode. De gewenste functionaliteit wordt in de vorm van requirements tot in detail vastgelegd en het ontwikkelproces wordt volgens een vaste structuur - analyse-ontwerp-bouw-test - doorlopen met afgebakende activiteiten. Sterk aan de watervalmethode is dat deze structuur een doorgaans zeer complex ontwikkelproces biedt. Zeker in de beginjaren van de software engineering, de vroege jaren ’80, was een strakke fasering onontbeerlijk. De softwareonwikkelkennis en -vaardigheden waren destijds nog onvolwassen waardoor het ontbreken van een strakke planning en duidelijke afbakening in dit proces onherroepelijk tot chaos zou hebben geleid. In de loop der tijd raakte men door scholing en ervaring steeds meer bedreven in het ontwikkelen van software, waardoor de noodzaak om volgens een vast stramien met afgebakende taken te werken minder werd. Daarnaast begon men ook te begrijpen dat key-users niet continu met software ontwikkeling bezig zijn en dat het begrip voortschrijdend inzicht tijdens het project opgevangen moest kunnen worden.

In de praktijk bleek echter dat softwareontwikkelprojecten allerminst succesvol waren. Systemen werden vaak te laat en buiten budget opgeleverd en het gebeurde bovendien veelvuldig dat het opgeleverde systeem uiteindelijk helemaal niet aansloot bij de behoefte van de opdrachtgever. Niet zelden werd de opgeleverde applicatie geleverd met functionaliteit die op dat moment alweer achterhaald bleek te zijn. De belangrijkste oorzaak hiervoor is dat de traditionele ontwikkelmethoden en tooling niet goed de praktijk van softwareontwikkeling ondersteunen. Het eerder genoemde voortschrijdend inzicht is een belangrijke oorzaak van wijzigingsverzoeken. In de praktijk treden er daarom gedurende het proces nog allerlei veranderingen op in de functionaliteit en verwachtingen ten aanzien van het systeem. Bij de traditionele methoden is het lastig om dit soort veranderingen mee te nemen en tussentijds bij te sturen. Bij iteratieve methodes, met de Agile-methode als belangrijkste spelregel, kan beter worden ingespeeld op voortschrijdend inzicht. Het functionele resultaat wordt gedurende het hele ontwikkelproces nog meer de centrale leidraad, aangezien in korte ontwikkelcycli telkens stukjes functioneel werkende software worden opgeleverd die vervolgens getest kunnen worden. De Agile-methode doet bovendien meer recht aan het sterk veranderende krachtenveld waarin software ontwikkeld wordt, met alle stakeholders - opdrachtgever, ontwikkelaars, eindgebruikers - verenigd in één projectteam, korte en directe communicatielijnen tussen it-specialisten en mensen van de business, en een centrale rol van de key users.

Met ‘high productivity’ ontwikkelingstools komt de Agile-methode nog beter tot zijn recht. Met high productivity ontwikkelplatforms kan immers nog sneller software worden ontwikkeld. Ook zijn aanpassingen gemakkelijker door te voeren, omdat niet regel voor regel code doorlopen hoeft te worden en de tooling veel uitzoekwerk van mensen kan overnemen, met minder kans op fouten. In een traditionele omgeving is dit veelal een erg foutgevoelig proces. Je moet immers regel voor regel code doorlopen op zoek naar waar de wijziging moet plaatsvinden en wat de impact hiervan is op het totale applicatielandschap.

Korte oplevercycli van stukken functioneel werkende software en key user commitment zijn de kernfactoren binnen de Agile-aanpak en dat alles in een zo kort mogelijke doorlooptijd. Die aanpak komt regelmatig onder druk te staan als de projecten te lang duren. De key users zijn namelijk enerzijds intensief betrokken bij een agile-project en anderzijds druk bezig met hun gewone dagelijkse werkzaamheden. Naarmate projecten langer duren of uitlopen, zal het commitment van de key user onder druk komen te staan vanwege urgente operationele zaken die voorrang hebben. Bij het afhaken van deze key users komt de gehele agile-aanpak op losse schroeven te staan. Wie gaat immers feedback geven op de geleverde functionaliteit en input geven op de volgende backlog? De stelregel is hierbij; hoe korter de doorlooptijd van een agile-project, des te meer zekerheid je hebt dat de key users aangehaakt kunnen blijven. Daarbij kunnen high productivity tools een faciliterende rol vervullen, zowel qua doorlooptijd, als het kunnen adopteren van functionele wijzigingen binnen het huidige project.

Wat dat betreft sluit de toepassing van een high productivity-platform en de Agile-methode tegenwoordig een stuk beter aan bij hoe een softwareontwikkelingsproces in de praktijk verloopt. Een goed resultaat in de zin van binnen budget, op tijd en aansluitend bij de wensen en eisen is daarmee een stuk realistischer geworden. De enige uitdaging die rest is om it-afdelingen ervan te overtuigen dat het echt tijd gaat worden voor verder automatiseren van de automatisering.

Belangrijke beslissingen nemen bestuurders, medewerkers op grond van een immer groeiende berg aan data. Dan moet je een database hebben die razendsnel queries kan…

ja, die achterlijke it-afdeling weer, die krijg je maar niet overtuigd :-)

@felix Inderdaad: als iemand me kan uitleggen hoe ik creativiteit kan automatiseren dan hoor ik dat graag :-) Misschien moeten het eens omkeren: als de gebruikers nu eens opgevoed worden om realistische wensen en verwachtingen te hebben. Je kunt ook niet van Amsterdam naar Hawaii vliegen in een luie stoel met veel beenruimte voor 2 euro en in een half uur aankomen...

Software engineering is wel iets ouder dan 30 jaar. Joseph Marie Jacquard (1752-1834) was de eerste echte software engineer, die als een traditioneel ingenieur op het snijvlak van hard- en software werkte. Hij is verantwoordelijk voor het uitvinden van de ponskaart gestuurde weefmachine. (http://www.nwo.nl/onderzoek-en-resultaten/programmas/Jacquard/achtergrond) Software engineering uit de jaren 50, 60 en 70 van de vorige eeuw had veel kenmerken van wat nu 'agile' wordt genoemd.

Wat mij steeds weer verbaast is dat men kennelijk van mening is dat met toepassing van agile/scrum het fenomeen “voortschrijdend inzicht” is verdwenen. Kul, natuurlijk. Het risico daarop is eerder groter. Er wordt immers sneller besloten en sneller ontwikkeld. Als het er op aan komt is het slechts zo dat een verkeerde of onvolledig beschreven functionaliteit sneller wordt opgeleverd – het blijft echter verkeerde of onvolledige functionaliteit. Men komt er dus hooguit sneller achter dat er nog wat mist of dat er nog iets net even anders moet. En omdat steeds kleine stukjes werkende functionaliteit worden opgeleverd, zien we ook met agile pas na verloop van tijd of we echt op het goede spoor zitten. De verbetercyclus blijft derhalve gewoon draaien. Als we de illusie willen kweken dat het met een agile aanpak allemaal in een keer goed gaat zijn we verkeerd bezig. Agile heeft vooral een psychologisch effect. Dat is in dit stuk feitelijk goed beschreven. Hoe sneller gebruikers resultaat zien op basis van hun wensen , hoe gemotiveerder ze blijven om er serieus aandacht aan te besteden. Feitelijk boeit het dus niet of het goede geleverd wordt; het boeit vooral dat er geleverd wordt, anders haken ze af. Persoonlijk vind ik dat een slechte zaak en getuigen van slecht management (het lijkt een beetje op het tevreden willen stellen van verwende jengelende kinderen: “ik wil het en ik wil het nu! – anders hoeft het niet meer, Whééhhh!). Maar goed, ook – of juist – hierom wordt er dus grote flexibiliteit en creativiteit van de IT club gevraagd. En zoals @Brombeer al zegt: creativiteit kun je niet automatiseren. Het wordt tijd dat die gebruikers dat eens gaan zien.

@hk Mooie reactie, het is ook het idee wat ik krijg als ik lees over agile en scrum, het gaat niet over ruimte geven aan voortschrijdend inzicht maar over project controle en beheersing. Agile en scrum als management tools aangestuurd door de business, de product owner. Doe eerst maar een dak en dan is een kelder ook wel geinig. Micromanagement is een term die hier beter bij past. Vlug vlug snel snel hup in productie met nog bad practices op de koop toe. Software als commodity? Hoe houd je vat op iets wat niet altijd even goed voorspelbaar is, ICT projecten. Dat dit soort management methodes dodelijk zijn voor creativiteit lijkt me duidelijk. @BertWijgers Als Agile staat voor geven van ruimte voor voortschrijdend inzicht dan geloof ik het meteen over projecten uit de jaren 50, 60, 70. Dat is hoe software ontwikkeling werkt, al doende onwikkelt men zijn ideeen, gooit wat weg, herschrijft wat en kom je tot iets.

Als je het risico loopt dat commitment van key-users onder druk komt te staan waardoor de 'agile-aanpak op losse schroeven komt te staan', denk ik dat je een heel ander probleem hebt. Gebrek aan commitment is in ieder project (zij het waterval of Agile) gevaarlijk en daarom moet je mensen dedicated op het project hebben zitten, of althans een voldoende gedeelte van hun tijd. Anders zullen ze er zich ook nooit voldoende mee identificeren. Bij de scrum-aanpak zijn product owners vereist die de wensen van de opdrachtgever vertalen naar te ontwikkelen functionaliteiten. Deze personen zijn onderdeel van de teams, waardoor je niet het risico loopt dat ze weggekaapt worden. Dus eerst je projectteam op orde hebben, dan heb je geen gezeur van key-users die niet thuis geven. Daarnaast is Agile niet alleen voor ontwikkelaars, de rest van het bedrijf (management, operation, andere afdelingen) moet er ook mee om kunnen gaan. Ik denk dat dat in veel gevallen de crux is...

Wil je dagelijks op de hoogte gehouden worden van het laatste ict-nieuws, trends en ontwikkelingen? Abonneer je dan op onze gratis nieuwsbrief.

Alle rechten voorbehouden © 1995-2021 Jaarbeurs ( 0.6172sec)